collection

2. Vendor Notes and Comments

The following are various notes, including comments provided by vendors that reflect their findings and thoughts from the interoperability event.

The CALDAV server implementations had the easiest task at the event. Their job was to ensure the servers were available and to monitor the traffic from the various clients. As clients sent requests, various bugs were fixed and added to list of items that need to be repaired.

Several clients went through the CALDAV scenarios (details are attached to this report). Each time we hold the interoperability events, we uncover more bugs that each client and server repairs.

One thing noted was a difference in CALDAV specifications within products. The spec is now at version 8; however, some of the other clients and/or server were still only at version 7. This caused some things to not be able to be tested at this event. However, this is common when a draft is not a finalized RFC.

Some servers imported timezones well. Recurrence is not working yet for some of the clients. This shows how two vendors have two different interpretations of the same object.

One vendor had a few problems with timezone ids. They appeared to be too verbose for their product. There were little issues with starts and ends. The vendor said it was helpful to hear other issues.

Not every client supports RFC 2446 or 2447. These are the scheduling and email transport protocols. In general, it seemed that the majority of clients did not have much support for attendees, and as such, a vast portion of the testing scenarios were not applicable.

Vendor one noted they lack implementations of some of the more complex RRULE (like BySETPOS), and struggled with overridden instances of recurring events. Publishing and subscribing seemed to work quite well with all clients. Their CalDAV support is rather limited at this stage, but they were able to do basic event adding/deleting with all servers except for one. That vendor was running a different version of the spec, and as such, could not return their queries.

Vendor two reported the following items:

  • They currently support import and export of RFC 2445 iCalendar objects and also allow clients to publish and subscribe to calendars via Webdav.

  • Calendar objects from Vendor three were successfully published and subscribed to their calendars via Webdav. Webdav connectivity worked quite well.

  • They noted that they were not able to map Vendor one’s TZIDs to their timezones.

  • In this case, timezones were interpreted in UTC.

  • Their floating dates and all day events imported correctly into another vendor’s product.

  • They also successfully mapped the other vendor’s timezones to their internal timezones.

  • Their application did not correctly import private event status (CLASS:PRIVATE). This has since been fixed.

  • Vendor four noted that importing their ics object into Vendor two’s application worked well. Currently Vendor four does not support recurrence or timezones.

  • Importing one time event ics objects from Vendor five worked correctly. The sample recurring event instance provided from Vendor five included multiple DTSTART properties which is not valid and could not be imported. Importing their recurring events into Vendor five’s application worked for the most part. Import of a rescheduled occurrence of a recurring event left the original date in addition to the new date/time in Vendor five’s application.

  • When importing Vendor six’s ics files, timezone ID’s were not correctly mapped to their timezones. They had to implement enhanced mapping logic. Imported recurrence samples worked very well with all rescheduled events importing properly. Export of Vendor six’s client recurring event did not import correctly. The master event included only RDATE objects to specify recurrence set and did not include an RRULE which is not currently supported by Vendor two.

  • Vendor seven provided four sample ics files which all successfully imported. Examples included multiple timezones, all day events and recurrence. Vendor two exports include a custom attribute in the VTIMEZONE component which caused issues when importing into Vendor seven’s application. These should be ignored.

Vendor seven reported the following items:

  • A couple of bugs relating to Vendor eight’s handling of recurring events and EXDATEs.

  • An issue where they were PROPPATCH‘ing calendar collections (to set their display names). However, not all servers support this, and they need to ignore returned errors in this case.

  • A couple of Vendor five problems that were fixed, allowing tests to proceed.

  • A issue where they do not correctly interpret an empty multistatus response to a PROPFIND (Vendor five does this, and it’s allowed by the WebDAV spec), leading to a failure in creating calendar collections.

  • Updating events on Vendor six is broken right now, apparently because of a known issue with Vendor seven not preserving X-properties.

  • They are unable to parse .ics files from Vendor two — (a bug in the way we parse VTIMEZONE).

  • Some of the other vendors noticed that they are exporting events in UTC timezone incorrectly.

  • A couple of bugs in their subscription to http: ics URLs were uncovered.

  • There were initially some problems with Vendor five’s client that turned out to be a result of client and server having implemented different versions of the CalDAV spec.

  • Vendor five updated their calendar-query REPORTs to match the latest spec, but was unable to retrieve events from our application. This was tracked down to being an indexing issue, and was fixed. Subsequently, the testing ran OK.

  • After the above fix, Vendor three had similar behavior retrieving events. It turned out this was a result of PUT-ing illegal iCalendar data (an empty STATUS value in a VEVENT). Vendor three worked around the problem, and was able to proceed. However, our application should have rejected the initial PUT request: This problem is being investigated.

Vendor five reported the following items:

  • Vendor five more interested in finding out what worked and what didn’t than in actually following the test scenarios. So the matrix was filled in with what seemed to work and where problems were found.

  • Most of the other vendors didn’t actually send invitations but rather sent emails with the ICS file attachments that were then imported. Therefore there was not a lot of Accept and Decline testing done. Delegate, Counter and Reschedule was not tested with any vendors.

  • They felt it was very helpful and they are busy working on the problems they found.

  • They noted that their CALDAV implementation has problems with “@” in URLs. It also isn’t happy with PUT not returning an ETAG.

  • Their CALDAV application had problems with Vendor six’s Auto-added organizer.

  • Vendor eight doesn’t add a “calendar-access” DAV header.